Deploy a new instance (catalog-driven via `variantId` or explicit).
Authorizations
Pass a user JWT or a oag_ User API Key on the
Authorization: Bearer <token> header. Both are validated by
openapi-gateway against the Auth service.
Both credential types are user-scoped: every key (and every JWT) is bound to exactly one owner, and every route grants the caller full access to that owner's own resources. Cross-tenant access is denied by owner-ACL inside the handlers — there is no per-route scope vocabulary on this API.
Removed in v1.1.0: the legacy
agents:*/tasks:*/files:*/instances:*scope set has been dropped together with the403 insufficient_scopeerror. Existingoag_keys automatically gain full owner-level access and do not need to be re-issued. SDK calls that previously passedscopestocreateAPIKeyshould drop the argument. See the changelog at the bottom of this spec for the full migration note.
Body
Either supply a catalog variantId (authoritative — lifts
agentFramework / providerId / region / scheduling hints from the
variant) or provide an explicit agentFramework (+ optional
providerId). Client-supplied scheduling fields (ownershipPreference /
maxPricePerHour / resourceTypeHint) are not accepted here; the
catalog variant is the source of truth.
1281286464Free-form provider-specific configuration merged with the catalog config (catalog wins on key conflicts).
1281288192128Alternate name for providerConfig; same semantics. Used by the
variant-driven path to layer user extras (apiKeys / apiBaseUrls)
on top of the catalog config.
12864